/azp run

@PureWeen / @jsuarezruiz, We have analysed the test case (Issue1323Test) failure and found that the issue was caused by a button alignment-related issue. Previously, the button inside the page, which was added as a child within the TabbedPage, was not properly aligned in the center.

In this test case, the button was added directly as the content of the page without any additional properties. However, when the page was added as a child page within the TabbedPage, the button was not properly centered.

After the fix, the button inside the page, which was added as a child in the TabbedPage, was properly aligned in the center of the page.

The fix involved calling this.InvalidateMeasure(), which triggered a layout recalculation. This allowed the element within the TabbedPage to be measured and arranged correctly during the subsequent layout cycle.

As a result, the button was properly aligned in the center of the page. Previously, the layout measurements were not recalculated, which caused the button to be misaligned on the page.

Based on the current behavior after the fix, can we resave the current snapshot as the expected snapshot for this test case (Issue1323Test).

Button Alignment in the Page (Output image from the simple sample):

Page added as Child in the TabbedPge(Output image from the simple sample):

Testcase Image (Before Fix):

Current Testcase Image (After Fix):

/azp run

@BagavathiPerumal I've tried your pr with my app and it does appear to fix the issue, thanks!

@BagavathiPerumal I've tried your pr with my app and it does appear to fix the issue, thanks!

@Mark-NC001, Thank you so much for taking the time to test the PR with your app. We're truly glad to hear that it resolves the issue.

The test Issue1323Test related with TabbedPage and Navigation is failing on Windows. Small snapshot differences.

@jsuarezruiz, It looks expected behavior, as we already mentioned here, can we resave the current snapshot as the expected snapshot for this test case (Issue1323Test).

#26217 (comment)

/rebase

/azp run

Could be possible to include a test case for this changes?

In Appium, can minimize and maximize the Window (even change the Window size) using:

app.Driver.Manage().Window.Maximize();
app.Driver.Manage().Window.Maximize();

Let me know if can help in someway.

@jsuarezruiz, As suggested, I have tried recreating the test case using Appium but was unable to do so for this scenario. A NotImplementedException occurs when attempting to set the size value using testApp.Driver.Manage().Window.Size.

Exception details:

System.NotImplementedException: Unhandled endpoint: /session/2EDC486C-4A59-4E60-8C80-3EC866B72868/window/rect -- http://127.0.0.1:10100/ with parameters {
wildcards = (
"session/2EDC486C-4A59-4E60-8C80-3EC866B72868/window/rect"
);
}
at OpenQA.Selenium.WebDriver.UnpackAndThrowOnError(Response errorResponse, String commandToExecute)
at OpenQA.Selenium.WebDriver.ExecuteAsync(String driverCommandToExecute, Dictionary2 parameters) at OpenQA.Selenium.WebDriver.InternalExecute(String driverCommandToExecute, Dictionary2 parameters)
at OpenQA.Selenium.Window.set_Size(Size value)
at Microsoft.Maui.TestCases.Tests.Issues.Issue26103.VerifyTabbedPageScrollingBehavior() in /Users/bagavathi/Downloads/maui-fix-26103/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue26103.cs:line 25
at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)

Code:

using Microsoft.Maui.Controls.PlatformConfiguration;
using NUnit.Framework;
using UITest.Appium;
using UITest.Core;
namespace Microsoft.Maui.TestCases.Tests.Issues
{
    public class Issue26103 : _IssuesUITest
    {
        public Issue26103(TestDevice testDevice) : base(testDevice)
        {
        }
        public override string Issue => "TabbedPage - ScrollView not allowing scrolling when it should";
        [Test]
        [Category(UITestCategories.TabbedPage)]
        public void VerifyTabbedPageScrollingBehavior()
        {
            var testApp = (App as AppiumApp);
            if (testApp != null && testApp.Driver != null)
            {
                var originalWindowSize = testApp.Driver.Manage().Window.Size;
                testApp.Driver.Manage().Window.Size = new System.Drawing.Size(100, 200);
                testApp.WaitForElement("stackLayout1");
                VerifyScreenshot();
                testApp.Driver.Manage().Window.Size = originalWindowSize;
            }
        }
    }
}

I also tried creating a test case based on a button click to change the window size, but this approach did not reproduce the issue. The issue only occurs when resizing the window by dragging. Could you please share your suggestions on how to resolve it.

There are some TabbedPage Windows tests failing.

Issue1323Test Snapshot different than baseline: Issue1323Test.png (0.90% difference) (in red, the differences)

TestPageDoesntCrash

 at UITest.Appium.HelperExtensions.Tap(IUIElement element) in /_/src/TestUtils/src/UITest.Appium/HelperExtensions.cs:line 302
  at UITest.Appium.HelperExtensions.Tap(IApp app, IQuery query) in /_/src/TestUtils/src/UITest.Appium/HelperExtensions.cs:line 38
  at UITest.Appium.HelperExtensions.TapMoreButton(IApp app) in /_/src/TestUtils/src/UITest.Appium/HelperExtensions.cs:line 2261
  at Microsoft.Maui.TestCases.Tests.Issues.Issue2809.TestPageDoesntCrash() in /_/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/XFIssue/Issue2809.cs:line 19
  at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
  at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)

Could you review if are related with the changes?

@jsuarezruiz,

Case1: Issue1323Test

It looks expected behavior, as we already mentioned here, can we resave the current snapshot as the expected snapshot for this test case (Issue1323Test).

#26217 (comment)

Case2: TestPageDoesntCrash

I have verified that the test case failures are unrelated to the fix. This has been confirmed on a local machine.

/rebase

/azp run maui-pr-uitests

Please review the ai's summary :)

I have reviewed the AI summary. The Arrange() call in the NavigationView.SizeChanged method is necessary to prevent test failures. Without this change, the ChangingToNewMauiContextDoesntCrash test consistently fails with a TimeoutException.

/rebase

🏷️ Test Categories for Regression Detection

No [Category] attributes were found in added test lines, but the changed source file (TabbedPage.Windows.cs) and updated Windows snapshot images indicate TabbedPage is the affected area. Categories were inferred from the source path.

UI Test Categories

Pipeline filter: TabbedPage

Device Test Categories

Recommendation: Run device tests: Yes — Windows-specific TabbedPage platform handler code changed.

🚀 Run Targeted Tests on Existing Pipelines

Both maui-pr-uitests and maui-pr-devicetests now support category filtering parameters. To run only the relevant tests for this PR:

UI Tests — trigger maui-pr-uitests with:

Parameter: uiTestCategories = TabbedPage

Device Tests — trigger maui-pr-devicetests with:

Parameter: deviceTestCategories = TabbedPage

When triggered without parameters (e.g., by normal PR push), all categories run as usual.

ℹ️ Categories are detected from [Category()] attributes in the diff and inferred from changed source file paths.

🏷️ Category detection by Detect Test Categories for Regression Detection

🚦 Gate — Test Before and After Fix

👋 @BagavathiPerumal — new gate results are available. Please review the latest session below.

@copilot write tests for this PR

@copilot write tests for this PR

🤖 AI Summary

👋 @BagavathiPerumal — new AI review results are available. Please review the latest session below.

void OnNavigationViewSizeChanged(object sender, SizeChangedEventArgs e)
{
    if (_navigationView != null)
        this.InvalidateMeasure();
}

🤖 AI Summary

👋 @BagavathiPerumal — new AI review results are available. Please review the latest session below.

📊 Review Session — 4eb69f6 · fix-26103-Resaved the test image. · 2026-04-12 15:56 UTC
🔍 Pre-Flight — Context & Validation
Issue: #26103 - TabbedPage - ScrollView not allowing scrolling when it should Related Issues: #11402 - TabbedPage app on resize hides page bottom content; #20028 - TabbedPage layout misalignment on window resize PR: #26217 - [Windows] TabbedPage: Refresh layout when NavigationView size changes Platforms Affected: Windows (fix), snapshot updates affect Windows UI tests Files Changed: 1 implementation, 6 test snapshots (no new tests added) Gate Result: ⚠️ SKIPPED — no tests detected

Key Findings

• Root cause: OnNavigationViewSizeChanged only called this.Arrange(_navigationView) without first invalidating the measure cache, so the layout pass used stale measurements after a window resize, causing scroll content to be clipped.
• Fix: The PR adds this.InvalidateMeasure() before the existing this.Arrange(_navigationView) call inside the null-guard block.
• Concern from reviewer (PureWeen): Asked whether Arrange() is even needed and whether InvalidateMeasure() alone suffices. The PR author claims removing Arrange() causes the ChangingToNewMauiContextDoesntCrash test to time out. This claim has not been independently verified.
• Comment from inline reviewer (jsuarezruiz): Suggested adding a test using Appium Window.Maximize()/Window.Minimize() to reproduce. Author attempted but could not successfully reproduce via Appium test.
• Reporter confirmed fix works: Issue reporter (Mark-NC001) tested PR and confirmed ScrollView now scrolls to the bottom correctly.
• No new tests added: PR author argues window resize is not automatable. Gate skipped since no tests present.
• Snapshot changes: 6 TabbedPage Windows snapshot baselines were updated because the layout is now more correct (items better aligned). This is an expected side-effect of the fix.
• Inline comments: One unresolved review thread — PureWeen's question about whether Arrange() is still needed.
• Prior agent reviews: None (only an AI summary posted by the PR author, not an agent review).

Fix Candidates

Source Approach Test Result Files Changed Notes

PR PR #26217 Add InvalidateMeasure() before existing Arrange(_navigationView) call in OnNavigationViewSizeChanged ⚠️ SKIPPED (no tests) TabbedPage.Windows.cs + 6 snapshots Original PR; Arrange() kept to prevent test timeout per author
🔧 Fix — Analysis & Comparison

Fix Candidates

Source Approach Test Result Files Changed Notes

1 try-fix (claude-opus-4.6) Replace this.Arrange(_navigationView) with _navigationView.InvalidateMeasure() to let WinUI's layout cycle handle re-arrangement ⚠️ BLOCKED TabbedPage.Windows.cs Compiles cleanly, unit tests pass; device tests unavailable
2 try-fix (claude-sonnet-4.6) Directly measure+arrange _displayedPage using _navigationFrame.ActualWidth/Height (content area dimensions) ⚠️ BLOCKED TabbedPage.Windows.cs Compiles cleanly; device tests unavailable
3 try-fix (gpt-5.3-codex) Dual invalidation (InvalidateMeasure + InvalidateArrange) on both this and _navigationView, no explicit Arrange() ⚠️ BLOCKED TabbedPage.Windows.cs Compiles cleanly; device tests unavailable
4 try-fix (gpt-5.4) _displayedPage.InvalidateMeasure() + platform view fallback invalidation ⚠️ BLOCKED TabbedPage.Windows.cs Compiles cleanly; device tests unavailable
PR PR #26217 Add this.InvalidateMeasure() before existing this.Arrange(_navigationView) call in OnNavigationViewSizeChanged ⚠️ SKIPPED (Gate) TabbedPage.Windows.cs + 6 snapshots Original PR

Cross-Pollination

Model Round New Ideas? Details
claude-opus-4.6 2 Yes Key insight: this.Arrange(_navigationView) uses FrameworkElementExtensions.Arrange (line 184) which has a guard: if (!view.Frame.Equals(rect)). This means if MAUI Frame already matches the current NavigationView dimensions, the arrange is silently skipped. New ideas: (1) Bypass guard with e.NewSize directly calling VisualElement.Arrange(Rect) unconditionally; (2) Defer layout to next dispatcher tick via DispatcherQueue.TryEnqueue; (3) Subscribe to _navigationFrame.SizeChanged instead; (4) Use WinUI _navigationView.UpdateLayout()
Exhausted: Yes — all 4 models + cross-pollination completed

Key Infrastructure Finding: All Windows device tests (including ChangingToNewMauiContextDoesntCrash) blocked with WindowsAppSDKSelfContained requires a supported Windows architecture. Unit tests pass for all approaches.

Selected Fix: PR #26217 — No attempt could be validated over the PR's fix due to device test infrastructure unavailability. The PR's approach (InvalidateMeasure() + Arrange()) is the most tested fix (reporter confirmed working). However, PureWeen's concern about the Arrange() call inside SizeChanged remains unresolved. The cross-pollination insight about the FrameworkElementExtensions.Arrange guard (line 184) is relevant — if the guard is the real root cause, bypassing it with e.NewSize might be cleaner.

📋 Report — Final Recommendation

⚠️ Final Recommendation: REQUEST CHANGES

Phase Status

Phase Status Notes
Pre-Flight ✅ COMPLETE Issue #26103 (Windows TabbedPage ScrollView clipping on resize) + related #11402, #20028
Gate ⚠️ SKIPPED No tests detected in PR
Try-Fix ⚠️ BLOCKED 4 attempts, 0 passing — Windows device test infrastructure unavailable (WindowsAppSDKSelfContained requires a supported Windows architecture)
Report ✅ COMPLETE
Selected Fix: PR (no alternative could be validated)

Summary

PR #26217 fixes a Windows-only layout bug where TabbedPage containing a ScrollView fails to correctly update its layout after window resize. The fix adds this.InvalidateMeasure() before the existing this.Arrange(_navigationView) call in OnNavigationViewSizeChanged. This is a 5-line change to TabbedPage.Windows.cs plus 6 updated snapshot baselines.

The fix is confirmed working by the issue reporter. However, there is an unresolved reviewer concern from PureWeen about whether the Arrange() call inside SizeChanged is necessary and correct, and no new automated tests were added.

Root Cause

When the window is resized, the WinUI NavigationView.SizeChanged event fires. The original handler called this.Arrange(_navigationView), which uses the FrameworkElementExtensions.Arrange(IView, FrameworkElement) extension method (defined in FrameworkElementExtensions.cs:184). This extension method:

1. Builds a Rect(0, 0, frameworkElement.ActualWidth, frameworkElement.ActualHeight) from current NavigationView dimensions
2. Only calls view.Arrange(rect) if !view.Frame.Equals(rect) (guard to prevent redundant arranges)

The bug: view.Arrange(rect) does NOT call InvalidateMeasure() first. So when the layout pass runs, the MAUI measure cache still contains stale sizes from before the resize. The ScrollView child's DesiredSize is never re-measured with the new window dimensions, causing clipping.

The PR's fix correctly adds this.InvalidateMeasure() before this.Arrange() so that stale measurements are discarded before the arrangement pass runs.

Fix Quality

Strengths:

• ✅ Fix is minimal and targeted (5 lines changed in one method)
• ✅ Addresses the correct root cause (stale measure cache)
• ✅ Confirmed working by issue reporter (Mark-NC001)
• ✅ Snapshot updates are expected and correct (layout is now more accurate)

Concerns requiring author response:

1. ❓ Is this.Arrange(_navigationView) still needed? — PureWeen asked whether InvalidateMeasure() alone suffices. The PR author claims removing Arrange() causes ChangingToNewMauiContextDoesntCrash device test to time out. This claim should be independently verified. Calling Arrange() inside a SizeChanged handler of the same view is architecturally unusual and could cause layout re-entrancy issues.
2. 🔍 Consider bypassing the extension method guard — The FrameworkElementExtensions.Arrange extension has a frame-equality guard. If the new size matches the MAUI Frame (e.g., when window is restored to its original size), the arrange is silently skipped. A more robust approach may be: this.InvalidateMeasure(); this.Arrange(new Graphics.Rect(0, 0, e.NewSize.Width, e.NewSize.Height)); using e.NewSize from the event args to bypass the guard unconditionally.
3. ⚠️ No new tests — The Gate was skipped because no tests were added. The reviewer (jsuarezruiz) suggested using Appium's app.Driver.Manage().Window.Maximize() / Minimize() to test window resize behavior. This is technically feasible and should be explored.
4. 🧹 Inline code comments — The two inline comments added (// Ensure TabbedPage layout responds to NavigationView size changes, // Complete layout to fix frame dimensions) do not add significant clarity over the code itself and should follow the repo convention of minimal comments.

Recommendation Details

The fix is functionally correct based on reporter confirmation and code analysis. However, the open reviewer question about Arrange() necessity plus the absence of tests leads to a REQUEST CHANGES recommendation. The author should:

1. Address PureWeen's concern about Arrange() vs InvalidateMeasure() alone with a reproducible test or CI evidence
2. Consider using e.NewSize to bypass the extension guard for robustness
3. Explore adding a window-resize UI test as jsuarezruiz suggested
4. Remove or simplify the inline code comments to match repo style

I’ve reviewed and updated the changes based on the latest findings. Specifically:

• The reason for using Arrange(_navigationView) has already been updated in the comment. It is currently required to prevent failures in ChangingToNewMauiContextDoesntCrash.
• The code has been updated based on the suggestion to bypass the extension method guard.
• The reason for not adding a test case for this fix has already been mentioned in the PR template and also clarified in the comments.
• Inline code comments have been removed to align with the repository style.